Serious security threat for ColdFusion servers [now covered by a hotfix]
Note: This blog post is from 2013. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.Hey folks, there's a fairly serious security threat out in the wild, and you may want to check if your server's been hit. (It may be old news to some, but for now it's hitting people in the past week or so.) It's been confirmed to have hit at least CF9 (9.01 and 9.0.2) servers, but it seems it would apply to as well to CF10 or down to CF 7, as it leverages the Admin API.
And note that it's NOT one that you're protected against by having applied CF security hotfixes. (Updated Jan 15 2013, as Adobe now has a hotfix for this. More below.)
There's quite a bit for you to consider regarding this recent threat, as I discuss here.
Two updates since first writing this entry:
- First, I have now struck out that last sentence and changed the title, as Adobe has come out with a fix for the problem today. See my entry, Part 3: Adobe hotfix released for "Serious security threat for #ColdFusion servers. But if you are coming to this entry for the first time, you will want to read the rest of this, and part 2, before going to part 3 (or if you go there just to get the hotfix applied first, do come back for more, as there's still plenty to consider beyond just the one problem and the one fix).
- Second, as I wrote here the night after I'd first posted this entry, I've had a lot more info to share and so created another entry, Part 2. Among the new information shared there are such things as how the hack worked (not too much detail, though), how to determine what the exploit may have exposed, how to handle resolving things for many sites via scripting, how to lock down the /adminapi and /administrator directories, and most important, why you should not skip all this just because "we already block all access to the CFIDE/adminapi" (and /administrator)". There may be exposure you're not considering. As one more update (on Jan 15) since posting this originally, the technote from Adobe indicates that we should also block unfettered public access to the CFIDE/componentutils directory, used for the component browser.
A Quick Overview
There's quite a bit that you should (and will want to) understand about the hack, which you can learn more in a thread on the Adobe CF Admin forum, where a poster first pointed it out on Friday, and I found that I too had been hit.
See the specific thread for more details, including a fairly substantial reply I offered (which he's marked as "the answer"), where I explain more I'd found about it, including how how it got there, how to confirm how it got there for you, how to rectify things, how one might already be protected against it, etc.
The upshot is that a file is put on your server which gives a hacker pretty much unfettered access to a lot of things including reading/downloading/uploading/renaming and creating files, accessing datasource information, and more. The file to look for is called h.cfm and is placed in the CFIDE directory (at least in the current rendition of the hack, which may very likely change when the hacker learns that it's being publicized.) See the forum thread for more on what specifically to look for.
Fortunately for some, the degree to which the hacker would have access to things may be limited by how careful you've been in other protections, such as explained in the various lockdown guides for CF (here for CF10, CF9, and CF8).
I also explain how, despite my own efforts to protect the AdminAPI folder through which the exploit happened, I still fell victim. Perhaps it could happen to others. And it will certainly likely happen to those who have not implemented any protection against that folder (whether blocking access to it by IP address, requiring additional authentication, or otherwise). More in the forum thread.
Why am I posting here, now?
I was torn whether to blog my answer to that forum reply when the thread was created, or write a reply there in the forum. I chose the latter, and pointed it out to Adobe and some other CF experts, waiting to see any reply, especially if perhaps it was "old news", as I didn't want to alarm people here if it was not. From some replies I've gotten (some not public), it does seem others have been hit.
Also, as I note there, it's always dicey publicizing discovery/resolution of a security breach, as it can open the door to copycats. I tried in the forum thread to avoid giving any info to open new exploits. I also waited a couple of days to see if any specific other response might be posted from Adobe or others. You'll see in the thread that Adobe has offered to investigate further. So with that, I wanted to now spread the word here, and in twitter (do share the word with others).
I suppose comments ought to be offered there on the forum, since Adobe and others (seeing that thread) will be looking there and not here. Still, I realize some may not have an Adobe forum account, or may simply prefer to respond here rather than there. I'll let you decide. I just wanted to get the news out in case anyone else may be hit.
That said, I do realize that some may prefer not to publicly acknowledge that they got hit by this, but if you want to offer an anonymous comment here to say if you did and/or if the info shared helped, feel free. I think it would help some to see that they are not alone in this.
For more content like this from Charlie Arehart:Need more help with problems?
- Signup to get his blog posts by email:
- Follow his blog RSS feed
- View the rest of his blog posts
- View his blog posts on the Adobe CF portal
- If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
- See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed
So what hotfix do you mean? Also, that link mentions no hotfixes. Indeed, it refers to an exploit, but it doesn't seem to be this one. There's no reference to adminapi (which is what this one used, without question).
I'm not trying to demean your attempt to help. I appreciate that you were trying. But I really don't want people to be left with some impression that you have provided "the answer". I just don't see it.
Not quite sure yet what the exploit has been used for (if anything), but at least that hole has been plugged.
I'm grateful to see that most are expressions of appreciation. Sadly, a lot of people have been hit by this, some just hours before the blog entry.
Some have asked for more info, and I've updated the entry with one clarification.
Others have asked for more info on how to lock down the /adminapi and /administrator directories.
There have been many blog entries discussing it, but do be careful that some are old (so things may have changed):
http://www.morgankel...
http://www.aaronwest... Administrator-in-Apache
http://www.petefreit...
http://www.petefreit...
http://www.clarke.ca...
http://www.raymondca... rotecting-CFIDE
http://www.michaels.... tion-on-windows
http://www.talkingtr...
I welcome if anyone has any more to propose. (I may just create a new one of my own.)
Of course, that also means that a lot of people have been hacked. I look forward to any possible fix that Adobe may come out with.
But in the meantime, let's all do lock down those /adminapi and /administrator folders from unfettered public access in our web servers!
http://helpx.adobe.c...
Don't know if that fixes it entirely, but I do know that I tried the exploit on my own servers, which have all optional security updates installed, and couldn't make it work.
If you're on Windows, I'd recommend the following free tool(s) to do it quicker and more effectively (in my experience)
http://www.carehart....
Anyway, no, that one is NOT the fix for the exploit being used in the case discussed in this entry. It's NOT a directory traversal exploit. As I said originally (in the forum thread and in the post, and in my reply), it's an adminapi exploit.
More specifically, that fix you point to is one that is included in 9.0.2 (because it was for 9.0.1 before 9.0.2 was built), so again, it is NOT a fix that protects against this (because I do already have it, and was exploited).
Hope that helps other readers.
And as for you, please don't take consolation in your having moved the CFIDE to another directory. That is NOT going to protect you in this case. The only protection is to prevent public access via your web server to files in the /CFIDE/adminapi folder.
I'll add that as an update to the entry above (since many people never seem to read comments.)
Our plan is to create blank copies of these files and set the permissions to read only for a specific user - any thoughts on whether this will be enough to limit this exploit, at least until Adobe release a patch (if they will?)?
Thanks for the blog post by the way, we always look but first time commenting.
Cannot thank you enough for putting yourself out there with reporting this. We were able to get in front of it and lock down both parts of our CFIDE directory (across all IIS sites) using IP restrictions. I'm trying to get our WAF rules set too as the first layer of defense. We too thought we had our administrator blocked...
@lukester, that would be an "interesting" approach. I'd just have deleted the files, rather then leave them there "blank". No one needs them to be there, and indeed the most important thing at the time would have been to block access to the vulnerable /CFIDE directories.
That said, just today Adobe did release a fix, which I discuss in a new part 3 entry, at http://www.carehart....
Anyway, thanks for the kind regards as a "first time caller, long time listener". :-)
@Lee, thanks also for your kind remarks. Also, note that the Adobe bulletins clarify that we want to also protect /CFIDE/componentutils as something not to leave open as unprotected. I just updated the blog entries to reflect that new info. While any current known vulnerabilities in there are indeed now fixed, there could be others that might appear later, so better to protect it now.
@Hemant, thanks so much for jumping in here that week and leaving that comment that you guys were working on this as "very high priority". I'm sure that was as comforting to others as it was to me.
Finally, @Tom, while you could "delete" the folders, that could be overly drastic. First, are you saying that you mean you'd have one copy of the CFIDE used by most sites that would NOT have these, and another used by some one site that WOULD have these directories? If that's so, are you then going to be careful when applying CF updates/hotfixes, when they tell you to extract (as the latest one does) a CFIDE zip over top of your current one, to make sure you do that in both places you now have copies? And what if someone else does that and doesn't know you have 2 copies?
Or perhaps you're thinking, "no, we just have one place for the CFIDE, and we'll delete these and add them back when we need to use the Admin". I know some who have said that. My warning still applies: when you (or someone else does) apply the update's extracted CFIDE zip, you will indeed have a CFIDE there to update (just not these directories you deleted).
Indeed, when the extracted hotfix files are placed over your current CFIDE, you will now have in those directories you had deleted only those few files provided by the hotfix, which could lead to still other confusion.
Just be very careful with the idea of "just removing the folders". The wiser thing, I think, is just to protect them, which I cover more in the Part 2 article.
(And Tom, do note as I said above to others that you now need to consider also removing/protecting the /CFIDE/componentutils, as Adobe says it has vulnerabilities.)
Finally, if anyone might be getting these blog comments as email, and doesn't know it, I have done a Part 2 and Part 3 with lots more info, and have a part 4 (post mortem) in the works. Check out the blog to find them.
We run multiple instances. So, if someone needs to manage the instance, they hit the instance port. Not *:80/cfide/administrator. Therefore, we remove it in the /cfide folder that is presented to the web sites. Along with adminapi and a couple other folders.
And to help address IIS' and CF's "back channel abilities" to still get to /cfide/administrator we put a handy little rewrite rule in blocking access should anyone sneak in on port 80.
Patching is no big deal. It's part of the documented process to update the public cfide folder.
And fortunately, Adobe has addressed the issue in CF10, even with multiple instances, by defaulting to having the CFIDE dir only within the cf10 folders (even if using IIS or Apache), and using a virtual directory for CFIDE in those to point to that. Then the CF10 updater knows automatically to update the "right" CFIDE folders. This should help avoid confusion over CFIDE updates...unless of course one starts creating their own copies manually. Forewarned is forearmed.
I was hit again this morning (before securing componentutils) and noticed them hitting the h.cfm file, which I had removed in the first attack. I decided to place the file back there, but I edited it to email me with their IP address and anything else I could grab. They hit it a short time later, and when I went to check the server I noticed they had REMOVED the h.cfm file! No surprise that the IP address came back to China.
I previously secured my cfide directory just by authentification + renaming the cfide virtual directory to a name of my choice... ( need to copy administrator/image and recreate a CFIDE virtual directory for this directory, and change script path in cf setting to point to new virtuel directory).
Beside passing the authentification they will have to guess for the folder name... I don't see what else to do...
It's really very important that people understand this issue, or they may think they are protected when they are still exposed.